home *** CD-ROM | disk | FTP | other *** search
- Date: Sat, 30 Jul 94 01:02 CDT
- From: ekl@sdf.lonestar.org (Evan K. Langlois)
- To: gem-list@world.std.com
- Subject: Re: Digested
- Precedence: bulk
-
- ========================================================================
- num Decimal number in ascii, 0xHexadecimal number
- geometry [ Width "x" Height ] [ "+" Xoffset "+" Yoffset ] - all in decimal.
- file Filename in ascii, extension gives clue to type. (full path only?)
- font <fontname>@<fontsize>
- ========================================================================
-
- Hmm .. Here's a nifty trick that is better than geometry settings.
- Use shel_get() to read the desktop inf file and place your windows
- where the desktop does. Now, since you don't want to put windows
- on TOP of each other for different apps, use the window handle
- as an index (can we assume that window handles are always allocated
- sequentially?) Then you can set the position and size of every window
- on your system and save desktop. Only problem is that the desktop itself
- won't index properly and some windows will be stacked on top of each
- other. But, its an idea. Geometry limits everything to a set size
- and position relative to the last window (or 0) so windows still stack.
- You could still use shel_get and forget using window handles as a
- index, and just stack the application windows on top of the desktop's.
-
- Hmm .. I don't think a full path is needed. Applications shouldn't
- change from the working directory so making things relative to that
- shouldn't be too hard. For global settings you either use the full
- path, or if you want to access a different file for each application
- with one global setting, then make it relative.
-
- Why anyone would do such a thing is beyond me.
-
- Are font sizes in points or pixels? Anyone have any good code to
- convert between the two? Say, if I have a 10 point font, and I
- want to scale it to 11 point, how many pixels is that? NVDI scales
- fonts based on pixel size, and I think Speedo does too (not sure).
-
- ========================================================================
- <application-name>.<attribute-name>.<attribute-type>
- myWord.helpDialog.confirm.key: Return (attribute-name = helpDialog.confirm)
- ========================================================================
-
- Looks fine to me. Does the code you posted (it was you right, Warwick?)
- handle the dot in the center of the attribute properly? I mean what
- happens with :
-
- myWord.Help.key: Help
- myWord.Help.confirm.key: Return
- myword.Help.font.font: (attribute name of help.font)
-
- Will it take myWord.Help.font.font to be the same as myWord.Help.font
- and more importantly, SHOULD it?
-
- ========================================================================
- useful if they use your app with a program for which window redraws are
- expensive (eg. some DTP programs). It needs to be configurable so
- ========================================================================
-
- Calligrapher! Very expensive redraws! And it redraws the entire
- window twice after every dialog. I guess the programmer doesn't
- know about clipping those rectangles and waiting for redraw messages.
-
- ========================================================================
- The correct way to track every mouse movement is to watch a 1x1 pixel
- rectangle. This is documented in many places. (example uses are drawing
- programs and real-time drags)
- ========================================================================
-
- I like a snapped 8x8 rectangle. Less events, faster drawing (usually)
- and your icons can be snapped into place by hand instead of using a
- special function.
-
- ========================================================================
- ]If the button is no longer pressed when you process the message, top the
- ]window. This means that the button was tapped on the window with the intent
- ]to bring it to the front.
-
- Anything like that depends on how fast your machine is.
- ========================================================================
-
- Technically yes, but if its done RIGHT after the evnt_multi then it
- should be OK. I don't think the code I posted is gonna vary at all
- between machines even if you are VERY hard pressed for CPU. After
- all, evnt_multi returns after a sleep, and if you use the MiNT scheduling
- (assuming MultiTOS) then you have 2 time-slices, which is either 10ms
- or 2 vblanks, I can't remember, I'm tired, let's say a significant
- amount of time to complete the graf_mkstate call.
-
- However, I don't like press to click for background windows. If its
- faster to top the window than to wait for the click delay, then I
- really don't like it. And I think it gives a false security, making
- it even MORE dangerous than simply allowing selection when the object
- is fully visible.
-
-
-
-